Computers are often connected into a local area network (LAN) to enable exchange of information and sharing of resources. A local area network provides a distributed computing environment in which users can access distributed resources and process applications on multiple computers. One such computing environment, called DCE, has been implemented using software available from the Open Systems Foundation (OSF). In a distributed computing environment, a group of machines is typically referred to as a "domain." An OSF DCE domain is called a "cell." A DCE cell can be a complex environment involving hundreds of machines in many locations.
DCE includes a "Security Service" that provides secure communications and controlled access to resources in the environment through authentication, secure communication and authorization. To this end, the Service includes a Registry Service, an Authentication Service (AS), a Privilege Service (PS), an Access Control List (ACL) Facility and a Login Facility. The identity of a DCE user or service is verified, or authenticated, by the Authentication Service (AS) using a well-known authentication protocol called Kerberos. By integrating DCE remote procedure call (RPC) services with the DCE Security Service, network communications may be encrypted or otherwise checked for tampering. Access to resources is controlled by comparing the "credentials" conferred to a user by the Privilege Service with the rights to the resource, which are specified in the resource's Access Control List. The Login Facility initializes a user's security environment, and the Registry Service manages the information (such as user accounts) in the DCE Security Service database.
Known DCE implementations also include a centralized audit service. In DCE, all RPC-based servers are considered audit service clients. Typically, audit records are generated in the audit service through the use of an audit "code point" in a particular routine. The code point calls an audit API, which then passes information to the audit service for logging. An audit code point generally corresponds to an operation or function offered by an application server for which audit is required. Thus, for example, in a banking application, a server may have a code point set for opening or closing an account, withdrawing or depositing funds or a funds transfer operation.
In DCE, there is a set of code points in the Security Service that, theoretically, are useful for auditing the authentication operation. Several of these code points, however, are also designed to be used by the audit service to validate security information (so-called "tickets") that encode audit record data. Thus, it has not been possible to use the authentication interface as it was designed because whenever the DCE Security Service calls the audit API at a code point (e.g., to record a login), the audit API calls the Security Service to decode audit record data. This results in an RPC "deadlock." A similar RPC "bottleneck" occurs if the interface attempts to write an audit record for an unrecognized or invalid global (i.e. intercell) name that has been parsed from the user's login name. Because of these deadlock problems, it has not been possible to perform login auditing within a distributing computing environment, let alone from within the confines of the DCE Security Service.
This invention solves this important problem.